猎户座-持续打造爱奇艺海外高扩展性的策略引擎项目

‍海外策略引擎在去年年底已经上线第一版策略引擎 1.0，主要支撑了 Phone 后端的精细化运营等相关功能，具有后台配置简单，实现实时圈人功能，接口性能响应时间快等优势。海外策略引擎 1.0 的设计主要考虑的是与目前海外后端使用的 IQCard 相结合，着眼于快速支撑当时的产品需求。随着业务的不停迭代以及公司的降本提效的战略转移，精细化运营的使用场景和需要精细化运营的业务团队逐渐增多。在这种背景下，我们对策略引擎 2.0 进行了系统全面的设计，以期实现高效、稳定，灵活、可扩展，业务隔离的策略引擎。

本文主要介绍在策略引擎 2.0 项目建设过程中的一些经验和遇到的挑战和思考。

01

   项目基础信息

 实践中的痛点 

1、开发周期长

在产品运营使用策略引擎 1.0 的过程中，我们发现会存在很多使用新标签以圈定新用户人群的场景。一旦遇到这类场景，就需要进行开发去支撑新标签。这主要扩展性带来的开发周期长，效率低问题。

2、配置效率低

针对不同的业务方配置的后台数据，没有隔离，导致数据配置展示在一起，导致容易配置错误，也不利于快速找到各运营自己配置的数据。

 项目目标 

目标一：实现标签彻底的配置化

对于产品新增的标签需求，通过标签配置后台，即可配置指定标签数据从哪里获取。对于数据源或者获取数据后需要处理的标签，可以通过定制化的方式。但对于绝大多数的通用标签直接通过标签配置后台即可完成。

• 通用标签：用户画像数据和标签数据一一对应甚至是含义完全相同，不需要任何转化。这类标签通过标签配置后台指定数据源实现配置。
• 复杂标签：用户画像数据和标签数据有一层转化关系，即需要通过适当的逻辑关系转化才能将用户画像存储的数据与产品需要的标签数据对应起来。有定制转化逻辑，这就需要进行代码的定制化。此类标签主要通过标签配置后台和定制化代码共同完成。

目标二：实现业务隔离 

• 数据隔离：运营配置的数据只有该运营同一业务线的人才可以看到，同样，策略引擎获取数据的时候，只返回同一业务的数据。
• 流量隔离：某一业务线出现的流量异常情况不影响其他业务线的正常流量请求。更不能导致整个策略引擎系统故障。

02

   技术实现介绍

针对以上实践中的总结，我们希望提供一套通用的解决方案，去解决上文阐述的各种运营管理问题。以下将详细介绍我们思考和提出的解决上述问题的策略引擎方案项目，我们将其称为猎户座。

 总体架构设计 

策略引擎预留了给需要使用的相关功能的爱奇艺所有业务团队使用的能力。从项目设计初期，我们就尽可能对整个项目模块化，以期实现整个项目不同模块的解耦，方便后期的维护和扩展。策略引擎的主要有两个功能模块，一是管理后台  ，二是策略匹配服务。

其中管理后台主要用于标签管理，规则管理，策略管理以及让不同的业务方获取到自己创建的数据，以便和他们的内容绑定。策略匹配服务主要是用于实时圈人匹配，获取用户与策略 id 是否匹配。

 策略引擎后台介绍 

策略引擎后台包含标签管理和策略管理两大后台。维护了运营用户需要使用的全部标签以及根据标签创建的规则和策略数据。其中策略管理后台依赖标签管理后台生成的标签数据，策略管理后台维护圈人的策略数据。

为实现高扩展性的目标，针对标签管理后台，我们将标签进行各种不同维度的拆解，并且努力追求使得这些维度全部可配置，下面介绍一下几个重要概念。

标签通过不同的用户画像对人群进行分组，也就是我们常说的圈人。在实际圈人过程中，进行对比的是两组数据，后台配置的数据和用户实际属性数据。后台配置数据即 “标签+属性值” 。用户实际属性的数据来自于脸谱，BI以及端传入的第三方服务，我们统一称为 BMP （ DMP - Data Management Platform ）。

运营产品配置了一条圈人数据一般包含多个标签值的数据，比如 A 标签值为 a ， B 标签值为区间值大于 b ， C 标签为区间值小于 c ， D 标签为区间值在 d1 到 d9 双闭区间。只有满足以上全部要求的用户才会被圈中。

标签创建后被赋予数值即称为规则，一条或者多条打包的规则称为策略。用户匹配时需要满足一条策略的所有规则，才被称为圈人命中。

01 标签管理后台

从上述我们知道，规则是标签赋予了特定的值。在创建规则之前，需要先创建标签，为了实现高可扩展的产品目标，我们思考将标签配置化。归纳标签主要原始属性有以下七个：

1. 标签数值的数据类型
2. 标签所属的业务方
3. 标签所属分组
4. 标签支持的运算符
5. 标签的可选值
6. 标签从DMP中获取的字段
7. 标签进行的相关转化封装逻辑

一个标签的策略匹配包含两部分数据，一部分是策略后台配置的数据，一部分是用户画像得出的实际数据。为了标签实现高扩展型的目标，我们在标签配置的时候，添加上了相关的用户画像数据及相关信息，实现获取用户画像数据的可配置。

上面的标签 7 大属性中，前五个属性属于标签的后台配置属性，与策略相关。后两个属性和用户实际属性相关，主要便于获取用户的实际属性值。

下面将一一介绍标签属性的含义。

• 数据类型主要包含有， date 、 boolean 、数字型、字符串型等。一个标签只能有一个数据类型与之关联。比如年龄只能是数字，会员类型只能是字符串，而会员过期时间是一个日期。
• 标签所属业务方，主要对标签进行分类。策略引擎属于基础服务，需要被需要的业务方共同使用，不同的业务方可以按照自己需要配置不同标签。
• 标签所属的分组，为了方便策略管理后台的配置，将众多的标签进行归纳。该级别在所属业务方之下。
• 标签支持的运算符包含有存在于、小于、小于等于、等于、大于、大于等于、区间（左闭右闭）、区间（左开右闭）、区间（左闭右开）、区间（左开右开）等。一个标签可以同时支持多个不同的运算符。
• 标签的可选值，与标签值相关。该处又可分为，配置、调用第三方服务以及手动输入和时间插件。

标签配置除了需要设置后台配置属性之外，还需要设置用户实际的相关属性。策略引擎主要用于圈人，即后台配置的标签和用户画像的标签能否一一匹配，全部匹配即为命中，不匹配即不命中。

创建规则的时候，一方面需要指定标签使用哪种运算符，标签值的类型，以及标签的具体数值，另一方面，也需要知道实际的用户属性从 DMP 中具体哪个数据源获取，DMP 数据源内的字段是什么，以及如何进行字段转化。对于如何进行字段转化的原因是因为从 DMP 获取的数据很可能与后台配置的属性数据不直接映射，需要进行特定的转化。由此可知，标签的最后两个属性是为了方便策略匹配的时候应该如何获取数据源以及如何封装数据。

02 策略管理后台

策略引擎从开始设计之初就定位为基础服务，为有需求的业务方提供策略匹配圈人相关的全力支持。因此，针对不同接入的业务方，我们需要给出相关的标签，以便平台的管理和业务方的维护。

相同的标签在创建规则时，可以选择不同的运算符进行进行属性设置。一条策略包含不同的规则，不同的规则又包含相应的标签和标签值。

03 数据存储介绍

策略数据主要包含了标签名称，标签使用的运算符、标签设置的值，而一条策略数据又包含了多个规则，每个规则又可以只用不同的运算符，而不同的运算符对应的标签配置值又不一样。

• 场景化思考

举个例子，比如配置一条策略，包含如下几条规则， A 标签值为 a ， B 标签需要以字符 b 结尾， C 标签为的值在 c1 , c2 , c3 , c4 之间。D 标签大于 d ， E 标签在 e1 到 e2 之间，左闭右开区间。我们在策略数据持久化的时候，将主要的标签 id ，对应的运算符，数据类型以及标签值存储下来。

但是由以上的例子我们得知，不同的运算符对应的数值是不一样的，不单是数据类型，可能连数据值的个数都是不一样的。比如 A 标签为 1 个值，可能是 string 类型；C 标签是不固定个值， string 类型也可能是数字类型或其他类型；D 标签是 1 个值，数字类型；E 标签是 2 个值，数字类型。

因此，设计定义一个可扩展的数据格式是我们实践过程中的一个较大挑战。

• 可扩展的数据结构

（1）对于标签

对于标签的几个属性，实现配置化。在标签中，需要配置用户实际属性的地方，由于用户特征属性需要从多处获取，并且需要保留未来扩展性的要求，该处的数据结构设计考量的要点较多。需要预留很多的层级结构以便日后的拓展。

（2）对于策略

我们知道，策略由不同的规则组成，规则即为赋值的标签。通过以上场景化思考我们可以总结标签必须实现以下两个条件：

1.  每个标签可以自由选择运算符

2.  每个标签可以自由选择对应值的数据类型和个数

不同的运算符和不同的数据类型表明标签值类型和个数是不确定的，所以需要用较好的数据格式来覆盖不同的值场景。设计过程中，决定对标签值类型选择数组的形式存放，如果是区间，则放 2 个值，通过具体的运算符确定是区间的开闭情况。如果是存在于或者交集运算，则可以存放需要的多个数值。如果是等于大于小于运算，则存放一个数值。通过这种方式可以很好的解决上面的问题。

 策略引擎匹配服务介绍 

01 功能介绍

使用方通过策略管理后台查询到所有配置的策略，将策略与内容进行绑定，用户请求时，需要将用户身份信息 uid （用户 id ）以及 qyid （设备 id ）和内容绑定的所有策略给到策略引擎匹配服务，策略引擎匹配服务根据这些数据，匹配满足用户信息的策略id返回给使用方，使用方得到匹配的策略获取相应的内容，从而实现了不同人群展示不同内容的精细化运营。因此，整个策略匹配服务的功能如下：

1. 策略查询是找到使用方传入的策略 id 所对应的策略内容详情。主要包括有策略的 id 查找详情和无策略的 id 查找详情。
2. 特征查询即主要包含三块，通过 qyid 查找脸谱用户画像特征数据，通过 uid 查找脸谱用户画像特征数据，查找 Bi 用户画像特征数据。对于端上携带的用户信息则有接口直接传入。
3. 逻辑转化又可称为规则数据转化。通过策略查询，获取到策略管理后台配置的策略详情数据。策略详情数据包含一条或多条规则，而规则相对应的标签会指定特征数据的查找地址。逻辑转化具体的执行逻辑见下图。
4. 策略命中是将所有待匹配的规则进行对比，全部命中即为该条规则命中。

02 性能保障和扩展性思考

• 扩展性思考

策略引擎匹配服务投给接入方使用，为尽可能满足不同业务业务形态的要求，将策略匹配服务细分为有逻辑运算和无逻辑运算，新增了组策略的概念，预留了使用方自由拼接策略的能力，提高匹配服务的扩展性。

无逻辑策略组即组内策略相互独立，结构为 List < String >，策略匹配服务匹配不同策略内的每个规则，全部规则命中即该策略命中，匹配组内的每个策略。

有逻辑策略组结构不是一个 list ，而是一个 Map < String , List < String >>， key 存放组 id ， value 为一组需要打包匹配的策略 id 。逻辑算法可为与/或运算。当为与运算时，一组打包匹配的策略 id 全部策略命中，该组策略才命中。当逻辑运算为或时，只要打包匹配的策略只要一个策略命中，即改组策略为命中。

• 性能保障

策略匹配服务需要调用的第三方服务多，不同标签需要进行处理的逻辑复杂，不同规则包含多个标签，需要处理的数据量相对较大。因此，保障良好的接口性能是整个策略引擎项目的一大挑战。匹配服务的整体执行流程如下：

解决思路：

1. 对整个请求流进程全局梳理，对前后无依赖的执行归类为一步，每步内使用合适的并发执行。
2. 使用全局线程池，减少线程开销。

• 资源隔离

策略引擎供多业务线共同使用，为避免用户运营错配以及一条业务线的流量异常的情况，策略引擎做了以下工作：

1. 策略管理后台增加业务线和权限功能，产品运营只能看到属于自己业务线的内容；策略匹配服务校验业务线标示，只能获取本条业务线内的数据。
2. 策略匹配服务针对接入的业务方，提供业务方相关的 QPS ，一旦超过阈值，报警、降级过量请求，避免单条业务线的问题拖垮策略引擎而扩大影响范围。

03

    总结与展望

在策略引擎 1.0 上线投入使用一个季度后，我们总结了产品运营以及研发在使用过程中的相关的痛点，针对性的进行了一些思考和提出一些解决方案，本文主要介绍为解决痛点问题而详细设计和实现的策略引擎 2.0 项目。

对其主要的目标扩展性、隔离性和保持原先的性能好以及实时圈人等优点所做的工作和提出的一些实践方法。随着未来更多的项目接入进策略引擎，我们仍会持续接纳策略引擎用户的建议，持续迭代，以追求卓越的心态，持续满足策略引擎的用户要求，来为爱奇艺用户提供更好的精细化产品服务。

也许你还想看

 关注我们，更多精彩内容陪伴你！